接下來我們要來探討ES操作背後涉及到的原理
幫助我們整合以前學過的一些觀念

在ES中的基本資料操作主要分成以下四種：

1. Index：處理文檔並將其存在index中供未來使用
2. Delete：將文檔從inde中移除
3. Update：將文檔從inde中移除，並且index一個替代的新文檔
4. Search：對一個或是多個index進行檢索目標文檔，或是進行聚合

而其中index, delete與update可以被分類成寫操作，search則為讀操作
這兩天會針對寫跟讀操作來分別進行探討

寫操作

這邊我們用indexing來進行講解

1. 首先client發送請求，而coordinator node負責接收請求
   • 是這個cluster的窗口，接收請求並統合出最後的response回傳給client
2. 判斷是否需要處理ingest pipeline
   • 如果有就交由ingest node處理
3. 拿到資料資後，判斷request或是當初mapping有無設定routing，如果沒有就預設_id
   • routing的分配方式看這邊：https://ithelp.ithome.com.tw/articles/10315924
4. 根據routing value計算出文檔應該要存在哪個shard
5. 將請求發送至primary shard
6. primary shard針對文檔欄位的mapping決定是否需要經過analyzer處理
7. 進行indexing的處理
8. 在primary shard執行成功後，將請求發送至replica shard
9. replica shard都處理成功後，將回覆給primary shard
10. primary shard根據wait_for_active_shards參數，決定要等多少shard回覆後再回傳給coordinator
11. coordinator收到回應後，將其傳回給client
    

我們在第7步的indexing這邊再進行講解

1. 文檔進來後，會先存在memory buffer中，此時文檔還不能被搜尋
   • 避免記憶體掛掉時導致資料缺失，因此建立transaction log
     • translog會紀錄每一次ES操作，可以幫助index掛掉時，ES恢復index
     • translog每5秒刷新到磁碟中
2. 根據index.refresh_interval來決定refresh的時間間隔
3. 執行refresh時：
   • memory buffer的資料被寫入segment file中，此時還在記憶體，但是文檔能被搜尋到
   • 清空memory buffer，translog不受影響
4. 執行flush，也就是將記憶體中的資料存入磁碟中
   • 當translog太大或是過了30分鐘後執行
   • segment file永久化
   • 舊的translog被刪掉
     
     圖源：https://pdai.tech/md/db/nosql-es/elasticsearch-y-th-3.html

接著我們總結一下這樣寫操作中分別具備哪些性質：

1. 因為有translog與replica的機制，保證資料儲存的穩定性
2. 在性能方面
   • primary shard不用等全部replica的回覆
   • flush的機制避免每一次寫資料都要馬上就磁碟進行IO開銷
3. 在實時性部分，透過refresh機制能讓segment file能快速被搜尋到
   明天我們會繼續介紹讀操作背後的邏輯

參考資料
流程圖參考：
https://www.elastic.co/pdf/elasticsearch-sizing-and-capacity-planning.pdf
https://pdai.tech/md/db/nosql-es/elasticsearch-y-th-3.html
寫原理：
https://pdai.tech/md/db/nosql-es/elasticsearch-y-th-3.html